Feature/exception handler - #31
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 49 minutes and 12 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughUpdated security and error handling: tightened authorization rules, added custom forwarding for 401/403 to new error endpoints, introduced an ErrorController and global exception handler, added an error JTE template, and disabled Spring Boot's whitelabel error page. Changes
Sequence DiagramsequenceDiagram
participant Client
participant SecurityFilter as Security Filter
participant ErrorController as Error Controller
participant ExceptionHandler as Global Exception Handler
participant JTETemplate as error.jte Template
Client->>SecurityFilter: HTTP request
SecurityFilter->>SecurityFilter: Authorization/authentication check
alt Access Denied (403)
SecurityFilter->>ErrorController: Forward to /error/403
ErrorController->>JTETemplate: Render error(status=403, error="Access denied")
JTETemplate->>Client: HTML 403 page
else Authentication Failed (401)
SecurityFilter->>ErrorController: Forward to /error/401
ErrorController->>JTETemplate: Render error(status=401, error="You need to log in to access this page")
JTETemplate->>Client: HTML 401 page
else Other Exception
SecurityFilter->>ExceptionHandler: Exception propagated
ExceptionHandler->>JTETemplate: Render error(status, message)
JTETemplate->>Client: HTML error page
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/main/java/org/example/alfs/controllers/ErrorController.java`:
- Around line 12-23: In ErrorController, update the forbidden(...) and
unauthorized(...) handlers to accept forwarded non-GET requests and set the real
HTTP status: replace `@GetMapping`("/403") with `@RequestMapping`("/403") and
annotate the forbidden method with `@ResponseStatus`(HttpStatus.FORBIDDEN);
likewise replace `@GetMapping`("/401") with `@RequestMapping`("/401") and annotate
unauthorized with `@ResponseStatus`(HttpStatus.UNAUTHORIZED); keep the same Model
usage and return values, and add the necessary imports for ResponseStatus and
HttpStatus in the ErrorController class.
In `@src/main/java/org/example/alfs/exceptions/GlobalExceptionHandler.java`:
- Around line 11-26: The handlers handleResponseStatusException and
handleException need to set the actual HTTP response status before returning the
view; add a HttpServletResponse parameter to each method and call
response.setStatus(...)—for handleResponseStatusException use
ex.getStatusCode().value() and for handleException use 500—so the servlet
returns the correct HTTP status instead of 200 while still populating the model
and returning "error".
In `@src/main/jte/error.jte`:
- Around line 1-3: The template declares a required parameter "ex" that is never
used and not provided by ErrorController/GlobalExceptionHandler; remove the
"@param org.example.alfs.exceptions.GlobalExceptionHandler ex" declaration from
the error.jte header so only the actual parameters ("error" and "status") remain
declared, ensuring the template can render without the missing required "ex"
parameter.
In `@src/main/resources/application.properties`:
- Around line 4-5: The property key is incorrect: replace the unrecognized
spring.web.error.whitelabel.enabled with the correct Spring Boot property
server.error.whitelabel.enabled so the whitelabel error page setting is applied;
update the configuration entry that currently reads
spring.web.error.whitelabel.enabled=false to use
server.error.whitelabel.enabled=false.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 66663ce4-89cd-4567-8fff-caa170432657
📒 Files selected for processing (5)
src/main/java/org/example/alfs/config/SecurityConfig.javasrc/main/java/org/example/alfs/controllers/ErrorController.javasrc/main/java/org/example/alfs/exceptions/GlobalExceptionHandler.javasrc/main/jte/error.jtesrc/main/resources/application.properties
Added custom error handling and replaced Spring Boot whitelabel pages.
Summary by CodeRabbit